Amazon CloudFrontで専用IPによる独自SSLを試してみた

Amazon CloudFrontで独自SSLを使う際、SNI非対応のクライアントをサポートするために使用する「専用IP独自SSL」を試してみました。「専用IP独自SSL」設定のために必要な時間や「SNI独自SSL」と異なる名前解決結果のようすなどもまとめています。

#Amazon CloudFront

#AWS

清水俊也

2020.04.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

清水です。AWSが提供する高速・高パフォーマンスなコンテンツ配信サービス(CDN)であるAmazon CloudFrontで、独自SSL設定のひとつである「専用IP独自SSL」を試してみたのでまとめてみます。

CloudFrontに独自SSL（独自ドメインならびにその証明書）を設定する場合、「SNI独自SSL」と「専用IP独自SSL」の2種類から選択できます。前者はネームベースのバーチャルホストでHTTPS通信ができる仕組みで、クライアント側でもSNI(Server Name Indication)に対応する必要があります。SNI非対応のクライアントをサポートする必要がある場合は後者を利用します。この「専用IP独自SSL」ではIPアドレスとドメインが紐付けられるIPベースのバーチャルホストとして機能します。

CloudFrontの歴史としては、まず「専用IP独自SSL」として独自SSL証明書がサポートされました。当時も現在と同様、月額600ドルの追加費用が発生していた認識です。その後、「SNI独自SSL」機能がリリースされ、SNI対応のクライアント向けのみであれば追加費用の発生なしにCloudFrontで独自SSLが使用できるようになった、と記憶しています。

CloudFrontの独自ドメインSSL証明書対応を試してみた | Developers.IO

なお、以下、本エントリでは実際にCloudFrontの「専用IP独自SSL」を設定していますが、 月額600ドル（時間数で按分）の費用が発生 します。CloudFrontは基本的には従量課金で利用できるサービスですが、この「専用IP独自SSL」については固定で費用が発生する点に注意しましょう。

「専用 IP カスタム SSL」料金 - Amazon CloudFront | AWS

CloudFrontに専用IP独自SSLを設定してみた

それでは実際にCloudFrontディストリビューションに専用IP独自SSLを設定してみます。今回は、ディストリビューション作成時に「専用IP独自SSL」を設定するのではなく、一度「SNI独自SSL」で設定したCloudFrontディストリビューションに対して、「専用IP独自SSL」部分のみを変更する、という手順を取りました。

マネジメントコンソールでCloudFrontディストリビューション設定のGeneralの項目を編集します。まずこちらが「SNI独自SSL」で設定している状態です。

Custom SSL Client SupportでLegacy Client Supportを選択します。この選択をすることで、Security PolicyはTLSv1かSSLv3のみが選択可能になります。サポートするSSL/TLSプロトコルとして、TLSv1もしくはSSLv3を含める、とういうことになりますね。（参考）今回はTLSv1としました。このまま[Yes, Edit]で設定を反映させます。

どのぐらいの時間で設定が反映されるか

CloudFrontの設定変更後、およそ10分後にマネジメントコンソールで「Deployed」の確認ができました。ただしマネジメントコンソールを常に監視していたわけではなく、おおよそ1分に1度は確認する、ぐらいでしたので多少ズレはあるかと思います。ですが、通常の設定変更とおおよそ同様の時間で「SNI独自SSL」から「専用IP独自SSL」への変更ができたといえるのではないでしょうか。

CloudFrontの作成や更新時間が約5倍高速になりました | Developers.IO

なお、このCloudFrontの独自SSL証明書サポート当初、まだ「専用IP独自SSL」のみしか設定できなかったころや「SNI独自SSL」対応当初は、この「専用IP独自SSL」設定のために別途AWSへの申請が必要だったようです。Wayback Machineから当時のAWSのページを確認すると、たしかに招待状のリクエスト欄があるのがわかります。

2020/04現在では、「専用IP独自SSL」利用にあたり申請はいらなくなっていますね。ただし、「2つ以上の独自SSL証明書をAWSアカウントに関連付ける必要がある場合は上限緩和が必要」とのことですので注意しましょう。

専用IPに設定した場合の名前解決結果

「専用IP」ということで、設定変更前後のIPアドレスにも注目してみました。EC2（東京リージョン）のAmazon Linux内で以下の内容のシェルスクリプトをwatch -n 60 script.shで実行、名前解決結果を確認してみました。

#!/bin/sh

echo "date" 2>&1 | tee -a logfile.txt
date 2>&1 | tee -a logfile.txt
echo "dig dedicatedip-cf.shimizu.example.com" 2>&1 | tee -a logfile.txt
dig dedicatedip-cf.shimizu.example.com +short 2>&1 | tee -a logfile.txt
echo -n -e "\n" | tee -a logfile.txt

「SNI独自SSL」の状態では、以下のように4つのIPアドレスが返ってきます。

date
2020年  4月 29日 水曜日 12:01:37 UTC
dig dedicatedip-cf.shimizu.example.com
13.XXX.XXX.49
13.XXX.XXX.55
13.XXX.XXX.4
13.XXX.XXX.29

「専用IP独自SSL」に設定後は、以下のように1つのIPアドレスのみが返りました。

date
2020年  4月 29日 水曜日 12:11:37 UTC
dig dedicatedip-cf.shimizu.example.com
13.XXX.XXX.131

なお、このIPアドレスが変わったタイミングについても、CloudFrontディストリビューションの状態が「In Progress」から「Deployed」に変わったのと同様のタイミングでした。より詳細に言うと、IPアドレスの変更のほうが2分ほど速かったです。

SSL Labsでのチェック結果

QUALYS SSL LABSでのチェック結果についても簡単に触れてみたいと思います。

SSL Server Test (Powered by Qualys SSL Labs)

CloudFrontで「SNI独自SSL」の場合、まず以下のようにCloudFrontの4つのサーバが表示されます。

そのうちの1つを選択します。各詳細には今回は触れませんが、「This site works only in browsers with SNI support.」という表記があるのがわかります。

専用IP独自SSLを設定したCloudFrontディストリビューションへのチェック結果が下記です。まず4つのサーバについては表示されず、すぐに対象ドメインについてのチェック結果が表示されます。（表示自体に少し時間はかかりますが。）また「SNI独自SSL」の場合に表示されていた、「This site works only in browsers with SNI support.」が消えていますね。

さらに、Handshake Simulationの項目でAndroid 2.3.7などNo SNIなクライアントでの結果も表示されています。

専用IPは1つではない

以上の確認の中で気がついたのですが、専用IPについては1つではないようでした。具体的には、東京リージョンのEC2からの名前解決結果では「13.XXX.XXX.131」が確認できていたのに対して、QUALYS SSL LABSではIPアドレス「99.XXX.XXX.230」が確認できました。私の自宅の環境からは「13.XXX.XXX.231」です。また試しにus-east-1バージニアリージョンにEC2インスタンスを起動して名前解決してみたところ、こちらはIPアドレス「99.XXX.XXX.30」が確認できました。またタイミングでも変わるようで、バージニアリージョンで「13.XXX.XXX.106」なども確認できました。

Amazon CloudFront開発者ガイドの該当箇所にも「各エッジロケーションの専用 IP アドレスを使用する」という記載があります。そのIPアドレスは該当ドメイン専用に使えるとしても、ドメインがIPアドレス1つに結びついているのではない、という点には注意しましょう。

専用IPに直接アクセスしても403エラー

「専用IP独自SSL」、イメージとしてはVirtual Hostを設定していないApacheのようなのかな、と思いました。ということは、ドメインを指定せず専用IPに直接アクセスしてもコンテンツが返されるのでは？とも思ったのですが、これは勘違いでした。「SNI独自SSL」のときと同じように、CloudFrontの名前解決結果のIPアドレスに直接アクセスした場合は、403エラーとなりました。

以下は、「専用IP独自SSL」のIPアドレスににアクセスした場合の403エラーです。

以下が「SNI独自SSL」のIPアドレスにアクセスした場合の403エラー、内容は「専用IP独自SSL」と変わりませんね。

この検証にかかった専用IP独自SSLの費用

さて最後に、この検証にかかった「専用IP独自SSL」の費用についてもまとめておきましょう。専用IP独自SSL、月額600ドルとなかなか高額な料金ですが、時間で按分されるとのことです。今回はなる早で動作検証を終え、私の手元の集計 ^*1では、以下の時間の間「専用IP独自SSL」を設定している状態でした。

「SNI独自SSL」から「専用IP独自SSL」への変更
2020/04/29 21:03 (JST)
上記設定のDeployedをAWSマネジメントコンソールで確認
2020/04/29 21:13 (JST)
「専用IP独自SSL」から「SNI独自SSL」への変更
2020/04/29 21:32 (JST)
上記設定のDeployedをAWSマネジメントコンソールで確認
2020/04/29 21:45 (JST)

時間で按分、ということで1時間毎に費用が発生するとすれば、600ドル ÷ 30日 ÷ 24時間 = 0.8333 ドルという計算です。1ドル未満で検証は終えているはずです！こちらは実際に請求の明細が出たら記載予定です。

まとめ

Amazon CloudFrontで「専用IP独自SSL」を設定してみました。機能としては2013年からあったもので、私もこのころにはCloudFrontを使っていたのですが、正直なところ設定するのがはじめてでした！いつも「SNI独自SSL」ばかりだったもので。とはいえ現在でも、SNI非対応のクライアントに対応するための機能として抑えておきたいですね。個人的にはサービスリリース当時の情報、利用にあたりAWSに個別に申請（リクエスト）が必要、という点で少し混乱しました。（本文にも記載したとおり、現在は1つの証明書のみの利用であれば申請はいりません。）また月額600ドルと聞くと正直ビビるのですが、短時間の検証、動作確認なら比較的安価に実現できるのではないでしょうか。今回の「専用IP独自SSL」調査検証にあたりいろいろと有用なアドバイスをくれた同僚にも感謝です！！